Undocumented and unchecked: Exceptions that spell trouble

Modern programs rely on large application programming interfaces (APIs). The Android framework comprises 231 core APIs, and is used by countless developers. We examine a sample of 4,900 distinct crash stack traces from 1,800 different Android applications, looking for Android API methods with undocumented exceptions that are part of application crashes. For the purposes of this study, we take as a reference the version 15 of the Android API, which matches our stack traces. Our results show that a significant number of crashes (19%) might have been avoided if these methods had the corresponding exceptions documented as part of their interface

Type Checking for Reliable APIs

In this paper, we propose to configure at compiletime the checking associated with Application ProgrammingInterfaces' methods that can receive possibly malformed values (e.g. erroneous user inputs and problematic retrieved recordsfrom databases) and thus cause application execution failures. To achieve this, we design a type system for implementing apluggable checker on the Java's compiler and find at compile timeinsufficient checking bugs that can lead to application crashesdue to malformed inputs. Our goal is to wrap methods whenthey receive external inputs so that the former generate checkedinstead of unchecked exceptions. We believe that our approachcan improve Java developers' productivity, by using exceptionhandling only when it is required, and ensure client applications'stability. We want to evaluate our checker by using it to verifythe source code of Java projects from the Apache ecosystem. Also, we want to analyze stack traces to validate the identifiedfailures by our checker

The Evolution of C Programming Practices: A Study of the Unix Operating System 1973-2015

Tracking long-term progress in engineering and applied science allows us to take stock of things we have achieved, appreciate the factors that led to them, and set realistic goals for where we want to go. We formulate seven hypotheses associated with the long term evolution of C programming in the Unix operating system, and examine them by extracting, aggregating, and synthesising metrics from 66 snapshots obtained from a synthetic software configuration management repository covering a period of four decades. We found that over the years developers of the Unix operating system appear to have evolved their coding style in tandem with advancements in hardware technology, promoted modularity to tame rising complexity, adopted valuable new language features, allowed compilers to allocate registers on their behalf, and reached broad agreement regarding code formatting. The progress we have observed appears to be slowing or even reversing prompting the need for new sources of innovation to be discovered and followed

Evaluating Maintainability Prejudices with a Large-Scale Study of Open-Source Projects

Exaggeration or context changes can render maintainability experience into prejudice. For example, JavaScript is often seen as least elegant language and hence of lowest maintainability. Such prejudice should not guide decisions without prior empirical validation. We formulated 10 hypotheses about maintainability based on prejudices and test them in a large set of open-source projects (6,897 GitHub repositories, 402 million lines, 5 programming languages). We operationalize maintainability with five static analysis metrics. We found that JavaScript code is not worse than other code, Java code shows higher maintainability than C# code and C code has longer methods than other code. The quality of interface documentation is better in Java code than in other code. Code developed by teams is not of higher and large code bases not of lower maintainability. Projects with high maintainability are not more popular or more often forked. Overall, most hypotheses are not supported by open-source data.Comment: 20 page

Data-driven elicitation of quality requirements in agile companies

Quality Requirements (QRs) are a key artifact to ensure the quality and success of a software system. Despite its importance, QRs have not reached the same degree of attention as its functional counterparts, especially in the context of trending software development methodologies like Agile Software Development (ASD). Moreover, crucial information that can be obtained from data sources of a project under development (e.g. JIRA, github,…) are not fully exploited, or even neglected, in QR elicitation activities. In this work, we present a data-driven approach to semi-automatically generate and document QRs in the context of ASD. We define an architecture focusing on the process and the artefacts involved. We validate and iterate on such architecture by conducting workshops in four companies of different size and profile. Finally, we present the implementation of such architecture, considering the feedback and outcomes of the conducted workshops.Peer ReviewedPostprint (author's final draft

Scholarly Context Not Found: One in Five Articles Suffers from Reference Rot

The emergence of the web has fundamentally affected most aspects of information communication, including scholarly communication. The immediacy that characterizes publishing information to the web, as well as accessing it, allows for a dramatic increase in the speed of dissemination of scholarly knowledge. But, the transition from a paper-based to a web-based scholarly communication system also poses challenges. In this paper, we focus on reference rot, the combination of link rot and content drift to which references to web resources included in Science, Technology, and Medicine (STM) articles are subject. We investigate the extent to which reference rot impacts the ability to revisit the web context that surrounds STM articles some time after their publication. We do so on the basis of a vast collection of articles from three corpora that span publication years 1997 to 2012. For over one million references to web resources extracted from over 3.5 million articles, we determine whether the HTTP URI is still responsive on the live web and whether web archives contain an archived snapshot representative of the state the referenced resource had at the time it was referenced. We observe that the fraction of articles containing references to web resources is growing steadily over time. We find one out of five STM articles suffering from reference rot, meaning it is impossible to revisit the web context that surrounds them some time after their publication. When only considering STM articles that contain references to web resources, this fraction increases to seven out of ten. We suggest that, in order to safeguard the long-term integrity of the web-based scholarly record, robust solutions to combat the reference rot problem are required. In conclusion, we provide a brief insight into the directions that are explored with this regard in the context of the Hiberlink project